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(57) Abstract: A method of facilitating an e-commerce transaction, the method including: providing a set of trading parameters; 
accepting in respect of a first entity (3) a desired trading profile including desired values or ranges of multiple of said trading param- 
eters; and accepting in respect of said first entity (3) one or more further trading profiles including values or ranges of multiple of 
said trading parameters; establishing one or more functional relationships between variations in a key trading parameter and one or 
more other of said trading parameters; wherein each of said further trading profiles are equivalent in desirability or expected value 
to said desired trading profile, and said functional relationship can be used to determine a set of equivalent trading profiles having 
substantially desirability equal expected values equivalent to said desired trading profile and said further trading profiles. 
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E-COMMERCE TRANSACTION FACILITATION SYSTEM AND METHOD 

The invention relates to the facilitation of commercial transactions, and relates 
particularly to the facilitation of commercial transactions using electronic 
5 communications networks, otherwise known as e-commerce transactions. The 
invention relates to the facilitation of activities that occur within a real economic 
trading system by providing a mechanism by which the structure, dynamics and 
business process requirements of 'real' economic processes and emulated and thereby 
contributing to efficiently functioning markets and optimal transactional outcomes. 

10 Globalisation of the world economy and the increasing ubiquity of Internet 

usage has resulted in product markets becoming increasingly more competitive and 
immediate than ever before. Despite the immense interest in facilitation of business- 
to-business (B2B) transactions using e-commerce, a cost-effective and easily 
implemented B2B solution that provides comprehensive e-enablement for market 

15 search, e-procurement and e-sales functions that integrate with/to enterprises' back- 
office software systems is not generally in use. 

A model for economic interaction in the form of a computer-based system does 
not exist that provides a comprehensive solution that enables business enterprises to 
use the communications infrastructure of the internet to transact online within an 

20 economic environment/framework that possesses the structural characteristics of 'real' 
economic processes that are essential to producing optimal transactional outcomes. 
Moreover, existing tools are particularly inadequate to address the complexity 
associated with international transactions where the trade amounts are often 
significant. 

25 To date, Internet-based business systems that cater to facilitating commercial 

transactions between business enterprises (B2B) have been developed using economic 
frameworks that are seriously flawed. Numerous different models or configurations of 
so-called "digital marketplaces" have emerged in recent years. These existing models 
would appear to be based on an imprecise understanding and/or use of the technology 

30 that results in a distortion of fundamental economic principles. 

For example, the existing e-commerce models emphasise the notion of creating 
digital marketplaces. Two predominant models are the "business portal" that provides 
a centralised multi-product "retail or end-user" style model; or the "industry-specific 
marketplace" model. Although both purport to create digital marketplaces, these 
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models represent an electronic environment in which business contacts may be 
established that may lead to the eventual transaction of business. However, neither of 
these models are capable of capturing the subtle complexity of the dynamics 
underlying well-functioning markets. 
5 Until now, B2B e-commerce business systems have neglected to deal with the 

subtle, distinctions that exist between the concepts of markets, industries, firms and 
products. The failure to properly configure the processes that flow from the inter- 
relationship between these concepts has had the effect of creating artificial business 
environments rather than extending existing product markets. 

10 Instead, efficient and well-functioning digital markets must be configured 

within an economic framework that enhances and extends, rather than distorts, the 
competitive dynamics and structural relationships of existing patterns of economic 
activity and behaviour. 

The economic dimensions of commercial processes are complex and operate at 

15 many different levels. In a conventional context, the economic inter-relationships that 
combine to produce well functioning markets and resource-efficient business 
transactions arise from signals and feedbacks between buyers and sellers that are 
channelled through multiple forms of information networks. The Internet has 
challenged the conventional forms of information signals and feedbacks as the 

20 information network is capable of consolidation within a single medium. 

A consequence of the unification of information delivery within a single 
dynamic medium is the mistaken belief that a change in information network structure 
has the potential to change the principles underlying fundamental economic behaviour 
and relationships. This belief, however, is not accurate. In order for an economically- 

25 based business system to function consistent with first best principles of efficiency, 
systems must be designed to be consistent with, and enhance, economic structures and 
processes in order to deliver efficient market and transactional outcomes. 

In order to construct an efficient commercial delivery process within the 
parameters of electronic business networks, the Applicant has determined that it would 

30 be desirable for there first to be an identification and understanding of the structural 
inter-relationships between prevailing economic concepts/conditions that must be 
present within an economic system in order to generate efficiently functioning markets 
and optimal transactional outcomes. Second, it would be desirable for the business 
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process related transactional flows within and between information channels within the 
system to be clarified. 

Table 1 is a table of factors to help explain the conditions that the Applicant 
has determined to be desirable to embed within the structure of an efficiently 
5 functioning economic system. An optimised electronic B2B model should be capable 
of emulating the most critical of the subtle economic interactions that spontaneously 
occur under conventional circumstances. This has not yet been built into current 
electronic B2B models because no one has adequately articulated the composition of a 
unifying economic framework that could provide the system infrastructure for an 

10 electronic economic system. 

The foundation of the electronic economic system developed by the Applicant 
is based upon an inter-related set of three parametric conditions. Each parametric 
condition provides an ingredient required in order for the 'economic process' to 
function properly. The three system parameters are the: 

15 • equilibrium condition/force 

• optimisation condition/force 

• maximisation condition/force 

In an e-commerce applications context, each of the three parameters 
corresponds to an important systemic function that transpires within the framework. In 
20 order to simplify the arguments that will follow, Table 1 identifies the key 
relationships that will be discussed further below: 



Table 1: 



Parametric 
Condition 


Dimensional 
Characteristics 


Functional Attributes 


Application 
Purposes 


Equilibrium 


Structural 
mechanics 


The macroeconomic 
(market) to 

microeconomic (firm) 
inter-relationship 


Firm to market, 
firm to firm 
connectivity and 
data 

communication 
channels 


Optimisation 


Competitive 
dynamics 


Convergence of demand 
and supply 
forces/tensions 


User (strategic) 
behaviour- signals 
and feedbacks 


Maximisation 


Process efficiency 


Internal resource 
utilisation and allocation 


Task handling and 
management 
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decision-making 





In broad terms, an 'economic system' is the sum of a series of inter-connected 
sub-system relationships. The sub-systems are the generators of dynamic forces that 
each sub-system both injects into, and extracts from, the system in order to execute a 
5 'core business process'. Each sub-system, in turn, is comprised of a consolidation of 
task-oriented business processes that influence (feed into) the characteristics of the 
sub-system level process. 

The inter-relationship among the three above-referenced system parametric 
forces to be captured within an e-commerce model can be succinctly contextualised as 

10 follows. At the system level the predominant force is the well-functioning system's 
tendency towards equilibrium (i.e., the balancing of opposing dynamic (supply and 
demand) forces. At the sub-system level, the predominant function is to reach optimal 
demand-side or supply-side oriented transactional outcomes (the exchange function). 
The optimisation process, in general terms, is a function of the enterprise's business 

15 process driven tendency towards maximising resource (demand-side expenditure or 
supply-side revenue gains) relative to the market (equilibrium) benchmark. 

In a business process/transactional context, Table 2 is a table of factors that 
have a subtle, business process inter-relationship. The Applicant has developed a 
particular configuration of the direct and indirect economic relationships between these 

20 structural factors, that is implemented in a manner that, within the context of the 
medium, efficiently channels information flows to optimise the business process 
outcomes that correspond to those relationships. 



Table 2: 



Market Focus and Functions 


Transaction Focus and Functions 


Buyer 


Seller 


Demand 


Supply 


Industry 


Firms 


Product market 


Products 



25 

From a business process perspective, the commercial process can be viewed as 
having two discrete stages. First is a "market-oriented" dimension. Second, this 
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orientation subsequently shifts at a critical point in the commercial process to a 
specific "transactional focus". A feature that distinguishes the two are the subset of 
factors which represent the dominant forces that influence the discrete outcomes 
occurring at the evolving stages of a commercial process. 
5 The origin of a transaction begins with a buyer. Buyers, in economics, equate 

with a "demand" or the desire to satisfy a material need. In order to satisfy this need, 
the buyer conducts a vertical "drilling-down" or information gathering process that 
begins at a general level and moves to increasing degrees of specificity in identifying: 

• the product it wants more precisely (for example, a boat or a 
10 automobile; that is, what general industry); 

• where, or the source, from which the product can be obtained (for example, 
which firm supplies the product); 

• comparative product characteristics; ie, price, quality availability etc.. 

At this stage, the information gathering process is driven by, and conforms 
15 most closely with neo-classical demand theory. Within the context of competitive 
dynamics, the process explains how buyer-led demand-side forces are the predominant 
influence affecting the progress of the search from a general to specific refinement 
process. 

At the broadest level, a buyer will conduct a search within more general 
20 parameters - at the industry level. An industry, however, is most easily defined as a 
categorisation, typology, or grouping of firms that consists of those firms that operate 
processes of a sufficiently similar kind and could produce products that are close 
substitutes. Some firms within an industry will produce certain products, while other 
firms belonging to the same industry may produce an entirely different range of 
25 products. Although there will be a "market" for all products produced by the industry, 
clearly, there is no such thing as a single "industry market". 

The forum, or institutional environment in which the buyer exercises its 
demand-side influence takes the form of what is described as a "product market". 
However, a precise definition of what constitutes a "product market" is among one of 
30 the more elusive concepts in economics. In fact, there exists no single concept of 
exactly what is a market. One definition (the Lancastrian definition) asserts that 
markets should be thought of as being made up of "products having similar 
characteristics". A combination of these above definitions results in a concept that 



WO 01/69460 



PCT/AU01/00299 



-6- 

markets are a notional forum in which products having similar characteristics are 
exchanged. 

At a particular point in the buyer's decision-making process, a fundamental 
event in the spatial orientation of the demand-side processes occur. At the moment the 
5 buyer decides upon the specific type of product it is seeking, the decision-making 
process ceases to be vertical, and shifts to a horizontally oriented comparative analysis 
between like goods. 

The predominant demand-side function influencing this stage of the transaction 
is the comparative analysis conducted between products having the same or similar 

10 characteristics. If the Lancastrian definition of what constitutes a "product market" is 
used, it is at this point the buyer truly enters the "product market". 

As a consequence of the comparative analysis among goods which are close 
substitutes, the buyer will eventually select a particular product that most closely 
conforms to its demand requirements relative to the price it is prepared to pay for that 

15 good. In this way, the "selection-decision" is made. 

The relational configuration of a buyer seeking information and product 
specificity is a one (buyer) to many (sellers) (1:M) relationship. Therefore, buyer-led 
market activity takes the form of a buyer using the medium to identify sellers, compare 
the characteristics of the products they offer relative to the price indicated (signalled). 

20 Properly designed Internet demand-oriented mechanisms have the potential to increase 
the speed and efficiency with which the buyer conducts search, identification and 
comparison activities. Business system applications that emulate efficient "market 
activities" should be directed towards enhancing the search, identification and 
comparison functions. 

25 A search mechanism that links one buyer to many sellers through a centralised 

"portal" configuration is appropriate provided that the scope of the search is 
sufficiently comprehensive to identify and locate a wide enough number of suppliers 
and, ultimately, products to give the buyer a good approximation of the comparative 
characteristics of the products offered. 

30 However, existing e-commerce models utilise economic frameworks that create 

distorted and dysfunctional markets as a result of two errors of structural logic. 

First, centralised "portal" style models include within the market only those 
products that sellers choose to offer for sale within the system. This configuration 
resembles more an agency, distribution or retail sale arrangement rather than an 
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extension of existing markets. Goods are placed in an artificial environment in a retail 
sale style arrangement rather than reflecting cross-comparative attributes characteristic 
of true markets. 

Another structurally unsound attribute of the existing models is that the 
5 centralised market place which purport to facilitate sales create a shift from vertical to 
horizontal spatial functions at the wrong structural dimension. The mechanical 
implications of this occurrence is that it becomes impossible to optimally integrate 
subsequent functions which occur in the business process and which are discussed 
below. 

10 The selection decision described above ceases the vertical movement of 

market-oriented activities from general to specific. It also ceases the 1:M buyer to 
supplier relationship. The importance of this change is that another fundamental shift 
occurs by implication. Rather than having a "market" focus, the business process takes 
on a "transactional" focus. 

15 The focal point for this analysis alters in that previously it was a buyer:market 

relationship. Now by implication of the organisational structures of production, the 
focal point is the buyenselling firm relationship. 

In order to make a sale, the buyer must meet the seller's terms and enter the 
transaction process. A question now arises as to how to optimally configure the most 

20 efficient transaction process by building on, or extending from the vertical market 
functions described above. 

Transactional outcomes can be well-explained using classical and modern 
theories of the firm and neo-classical price theory. In addition, a horizontal supply- 
side transactional orientation is also consistent with concepts of supply-chain 

25 efficiency and efficient internal management structures. 

A organisational concept that is central to both theoretical principles is the 
concept of control of key supply-side functions. 

One view is that firms or business enterprises exist because they are an 
institutional structure that constitute an optimal mechanism for organising production, 

30 on the one hand, and exchange on the other. Both functions involve the generation of 
"transaction costs". In this regard, the firm can be seen as a form of interface between 
the production and exchange functions that exists because it is the structure best 
capable of most efficiently internalising transaction costs. 
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An optimal organisational structure minimises the transaction costs of 
production and exchange. In this lies a very strong argument that business transactions 
can be most efficiently conducted where the control and conduct of the transaction 
rests with the seller. 

5 The mechanics of this assertion relate back to the close relationship between 

signals and feedbacks. Firms formulate signals in response to feedbacks. However, 
signals can only be seen by the market to be adjusted at an external level where the 
firm has made some internal adjustment as a consequence of feedbacks. 

The product pricing decision is among one of the most fundamental decisions a 
10 firm makes. Price is a key market signal that can be quickly adjusted in the short-run, 
and can be used to indicate many messages ranging from product quality to the 
efficiency of the firm itself. 

A notable difference exists between the signal, or asking price, of a product. 
The ultimate selling price of a product is dictated by a number of closely related 
15 factors that are determined by circumstantial conditions. For example, the negotiation 
of a contractual price will be subject to, among other things: 

• volume discounts 

• payment risks 

• payment time 
20 • country risk 

• transport arrangements 

In brief, price negotiations are conducted in a manner that balances the relative 
influence of the price-related factors in determining a final sale price. 

Present e-commerce systems do not emulate real markets. Most can be 
25 classified as either being buyer (price-maker auction sites) or seller driven (fixed price- 
taker sites) that generate artificial or distorted market outcomes. In order to provide 
efficient and relevant e-commerce tool, transaction hubs cannot be restricted to a fixed- 
time, lot by lot sales process. Similarly, fixed priced sales mechanisms do not allow 
for rapid and dynamic adjustment of price relative to short-run seller strategies or price 
30 influencing factors such as those described above. 

In summary, the Internet is a communications network that possesses media 
and computational attributes that allow for the unification of information distribution 
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and processing functions that conventionally occur using numerous information 
distribution and processing channels. 

The market-related functions of the business process are demand-side led and 
involve a one to many relationship where the buyer's demands are met through an 
5 information gathering and analysis process that involves a vertical drilling down from 
a general to specific level. 

The Internet is capable of handling such functions through a centralised 
information gathering, categorising and sorting mechanism. To ensure the accuracy of 
information, it is desirable to take the information sought directly from the seller. 
10 Where the buyer identifies a specific product type it wants, it stops gathering 

information in a vertically flow and a spatial shift to a horizontal product-level 
comparison takes place. 

The selection decision is the critical point at which the buyer, by implication, 
enters a 1:1 relationship with a firm. Buyer-led, demand-side market related activities 
15 cease and supply-side forces begin to drive the business process. The process takes on 
a transactional orientation rather than market orientation. 

The institutional focal point for supply-side activities is the firm. The firm is 
an interface between markets and production that exists because it is the institutional 
structure that is most efficiently able to internalise transaction costs associated with 
20 market-related and production-related activities. 

In order to manage the inter-relationship between market-side and production- 
side functions, firms must control the signal/feedback process. Feedbacks are used to 
make internal adjustments. This, in turn, allows long-run adjustment of signals. In the 
short-run, the seller must control the pricing and negotiation processes in order to 
25 maximise flexibility in the pricing decision arising from strategic competitive 
decisions or the negotiated adjustment to factors affecting a final price outcome. 

Finally, horizontal control of the transaction process allows for supply chain 
fluidity and consistency. A horizontal distribution of transactional information flows 
allows for efficient integration of transaction outcomes across the supply-chain. 
30 The Applicant has determined that the implications for e-commerce of these 

considerations are that 'market-related' functions are best suited to take place within 
centralised search and consolidation configurations. By contrast, real product markets 
exist as extensions to firms in that they are institutional structures that produce and 
place goods in product markets. The nature of the supply-side transactional aspects of 
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the business process are made most efficient, and conform most closely to economic 
theory, where the key supply-side functions are controlled in a decentralised format by 
firms themselves. 

In order to provide the infrastructure for efficient market and transactional 
5 functions to take place, tools such as dynamic negotiating devices and fluid and 
comprehensive supply-chain integration processes are required from e-commerce 
business software. To date, no such tools are known to exist. 

Accordingly, there currently exists a need to address one or more of the various 
shortcomings of the existing systems and methods available for facilitating e- 

10 commerce transactions. 

The Applicant has recognised that commercial transactions can be 
advantageously facilitated within a systemic framework that is designed to emulate 
economic processes thereby providing a method by which business process activities 
can occur within a system structure that coordinates, communicates and facilitates 

15 timely and appropriate exchange of specific information to appropriate recipients, at 
various stages of the transaction process, results in efficiently functioning markets that 
promote optimal transactional outcomes, that is configured to accommodate 
international, intra-firm and domestic transactions which transactions are managed 
from pre-transaction through to post-transaction execution stages conforming to the 

20 transaction parameters. 

In particular, the Applicant has developed an economic system that enables an 
exchange/transaction process to occur within a framework that emulates real economic 
processes. The invention provides the basis for a system structure that is capable of 
achieving dynamic equilibrium. The equilibrium state is derived from a structural 

25 configuration that facilitates a balance through the interaction and alignment of 'near' 
equivalent dynamic supply (emanating from supply module) and demand forces 
(emanating the procurement module). The matching of supply and demand forces is 
further facilitated by business process activities that support the execution and 
management of exchange transactions by providing mechanisms that expedite the 

30 matching process. 

The structure of the system enables the matching of a firm's procurement 
requirements with suppliers of product items having information about those products 
located within markets, or supplied directly by other firms within the system or by 
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firms that are not part of the system but are given access to the system for the purposes 
of placing products within it. 

Preferably, the mechanism by which the matching of the first firm's 
procurement requirements with the product's offered for sale by a second firm is 
5 performed by a computer-based device that remains within the control of the 
respective firms. The respective matching mechanisms represent the procurement and 
sales modular components of a single device performing separate, but complimentary, 
buy and/or sell related functions. The procurement and sales components may interact 
with a third search/directory component that performs 'market-related' functions. 

10 In particular, the Applicant has recognised that commercial transactions are 

advantageously facilitated by obtaining information from one or more of the multiple 
parties involved in a commercial transaction to determine one or more possible sets of 
trading parameters that may be acceptable to the parties. Moreover, the Internet is a 
vast communications network which a large numbers of business enterprises can use to 

15 conduct business transactions. In this respect, the Internet is a powerful tool of 
communication that consolidates within a single medium, the ability of an organisation 
to transmit "outward" messages or signals to attract potential partner organisations to a 
business transaction while simultaneously permitting organisations to receive and act 
upon "inward" responses, or feedbacks, from external organisations. 

20 It is emphasised that the Internet is a tool that can directly enhance firms' 

"exchange" related functions (ie, interaction with markets and buyers) but indirectly 
enhances "internal production and supply" functions. In a direct sense, the Internet is 
capable of enhancing the "price and product" signals it sends to the market (in general) 
and buyers (in particular). The feedbacks from these signals can be used and 

25 interpreted to alter or adjust: 

• further external signals in the form of price relative to quality to assist 
in increasing and optimising market efficiency consistent with neo-classical 
price theory 

• operations of the firm to further improve process efficiency to further 
30 reduce unnecessary transaction costs. 

It is important that a firm is in an organisational position to receive and be 
sensitive to feedbacks. Here, there is a long-run and short-run adjustment dimension 
that must be considered. Over the longer run, firms use feedbacks to make internal 
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decisions and organisational adjustments that can then be efficiently signalled back to 
the market. In the short-run, firms can internalise feedbacks that may alter most 
powerful market signal - the pricing decision. It is at this point price theory plays an 
appropriate role in understanding business process. 
5 In order to emulate efficient, well-functioning markets, the pricing and 

negotiation decisions are preferably placed within the control of the seller. Since the 
price decision is a short-run decision, it is one that cannot be easily transferred to a 
third part to control on behalf of most sellers. Accordingly, any automated price- 
related tool is desirably within the seller's direct control for rapid adjustment response 
10 purposes, and is both dynamic and multi-parametric. 

From a supply-side perspective, and at the product market level of transactional 
specificity, the supply-chain moves horizontally from a firm's externally oriented 
market activities into its internal organisational and production oriented structures and 
functions. 

15 In order to optimise efficiency in the form of maximising price and quality 

signals to the market while simultaneously seeking to minimise transaction costs, it is 
preferable that a firm should control key functions of pricing signals (in the product 
catalogue), negotiation (transaction hub) and transaction management (post-transaction 
consolidation) and supply-chain responses (back-end internal integration into ERP 

20 systems). 

Accordingly, in a first aspect, the invention provides a method of facilitating a 
commercial transaction, the method including: 
providing a set of trading parameters; 

accepting in respect of a first entity a desired trading profile including desired 
25 values or ranges of multiple of said trading parameters; and 

accepting in respect of said first entity one or more further trading profiles 
including values or ranges of multiple of said trading parameters; 

establishing one or more functional relationships between variations in a key 
trading parameter and one or more other of said trading parameters; 
30 wherein each of said further trading profiles are equivalent in desirability or 

expected value to said desired trading profile, and said functional relationship can be 
used to determine a set of equivalent trading profiles having substantially desirability 
equal expected values equivalent to said desired trading profile and said further trading 
profiles. 
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Preferably, said first entity is a seller and said trading profile relates to the 
trading parameters desired by a seller. 

Preferably, a submitted trading profile accepted from a second entity can be 
compared against said equivalent trading profiles of said first entity to determine 
5 whether the submitted trading profile is more or less favourable to the first entity that 
said desired trading profile. 

Preferably, trading profiles are generated by or on behalf of said first and 
second entities with an intention to conduct a commercial transaction, are generated at 
least with a view to determining market demand or supply for a product or service to 
10 which said trading parameters of said trading profiles relate. Preferably, the first and 
second entities are respectively a seller and buyer, though in other embodiments these 
roles may be reversed. 

Preferably, said trading parameters include one or more of: price, volume, 
payment terms, credit terms, credit rates of interest. Preferably, said key trading 
15 parameter is price. 

Preferably, when said submitted trading profile is more favourable than said 
desired trading profile, a transaction between said first and second entities is initiated. 
Preferably, the terms of said transaction are based on a transaction trading profile 
which has trading parameter values which are derived from said submitted trading 
20 profile, and/or one or said equivalent trading profiles. 

Preferably, said one of said equivalent trading profiles is said desired trading 
profile, or an equivalent trading profile which is "closest" on a minimum squared 
distance measure or equivalent measure from said submitted trading profile. In other 
embodiments, said transaction trading profile is "between" said desired trading profile 
25 and said submitted trading profile, in the sense that the transaction trading profile may 
represent a compromise between terms of the desired trading profile, and terms of the 
submitted trading profile. 

Preferably, when said submitted trading profile is less favourable to said first 
entity than said desired trading profile, steps are preferably performed with a view to 
30 establishing a submitted trading profile and a desired profile that are compatible (ie 
said submitted trading profile being more favourable than said desired trading profile). 
This may involve a modification of the values or ranges of said trading parameters of 
said submitted trading profile and/or said desired trading profile. In such cases, it is 
preferably suggested to either or both of said first and second entities what changes 
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could be made to their respective trading entities to establish compatible trading 
profiles. 

In a further aspect, the invention provides a method of facilitating a 
commercial transaction, the method including: 
5 providing a set of trading parameters; 

accepting in respect of a first entity a desired trading profile including desired 
values or ranges of one or more of said trading parameters; and 

generating a metric representative of the desired trading profile; 
wherein said metric can be used as the basis for comparing said desired trading 
10 profile with a proposed trading profile. 

Preferably, the method further includes generating a metric representing the 
expected value of the desired trading profile. Preferably, the method further includes 
accepting from said at least one party multiple desired trading profiles having equal or 
substantially equal expected values. 
15 Preferably, in each of the equal or substantially equal desired trading profiles, 

at least the trading parameter of price is different in each profile. Preferably, in each of 
the equal or substantially equal desired trading profiles, changes in price are indexed 
against each of the other trading parameters besides price. 

Preferably, in each of the equal or substantially equal desired trading profiles, 
20 the sensitivity of the trading parameter of price is quantified against each of the other 
trading parameters. Preferably, this relationship is quantified by an approximate 
mathematical expression. This relationship may be linear or nonlinear in one or more 
of the trading parameters. Preferably, the sensitivity of price against each of the other 
trading parameters is independently quantified. 
25 Preferably, parties to the transaction at least include a buyer and a seller. In some 
embodiments, the parties to the transaction include a seller and multiple prospective 
buyers. In this case, the method may further include auction-based techniques. 

Advantageously, calculations are performed to determine one or more sets of 
trading terms which agree with the desired values / ranges of the at least two parties. 
30 Preferably, the prospective buyer and the prospective seller are respectively 

identified by a search based on a product and/or service classification code. 

In a another aspect, the invention provides a method of identifying prospective 
partners in a commercial transaction, the method including: 

providing a product and/or service classification code; 
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providing a database of records relating to respective business entities, said 
records including information, indexed according to said classification code, recording 
at least one product or service provided by or required by said entity and at least one 
desired trading profile in relation to said at least one product or service; 
5 performing, in response to supplied search information including at least one 

classification code, and at least one submitted trading profile, a search of said database 
for entities having a desired trading profile at least compatible with said submitted 
trading profile. 

Preferably, said classification code is organised in an hierarchical manner, so 
10 that search information of variable specificity or granularity can be provided. 
Preferably, said classification code is, or is based on or derived from an internationally 
recognised product and/or service classification code. Preferably, the classification 
code is, for example, the Harmonised Tariff Code, or HTC. 

Preferably, the search information optionally includes supplementary 
15 information specific to business organisations, such as geographic region, desired 
trading terms, credit profile etc. 

Preferably, the results of the search can be ranked by one or more 
predetermined criteria. 

Preferably, a number of search fields can be optionally specified in the search 
20 information to increase the specificity of the results of the search. 

Preferably, the search is performed by a particular user, and search information 
preferences specific to that particular user are taken into account when conducting the 
search. 

In particular, the search and negotiation stages of the transaction may provide a 
25 configuration of trading parameters that set the terms of an executable sales contract. 
The configuration choices made by system users can result in a series of permutations 
and combinations of business process tasks that must be completed before the 
transaction will qualify as being executed. The business process tasks must be 
executed conforming to the transaction outcome requirements. 
30 Preferably, the contract execution process involves the satisfaction of any one 

or more of transport and logistic functions, banking or financial functions, insurance 
and inspection functions, and the adjustment of production, planning and inventory 
functions within the selling firm. 
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The coordination of the execution of these functions may be conducted in a 
manner whereby each step in the execution process contract execution process must be 
satisfied in a stepwise manner in order to minimise use of resources and risk associated 
with contractual non-performance or failure on the part of either party to the contract. 
5 Embodiments of various aspects of the invention are advantageously 

implemented in computer software enabled devices and systems. Further, it is highly 
desirable that embodiments of various aspects of the invention are implemented with 
the assistance of a communications network, such as the Internet. 

In order to assist in arriving at an understanding of the invention, a preferred 
10 embodiment is illustrated in the attached drawings. However, it should be understood 
that the following description is illustrative only and should not be taken in any way as 
restricting the generality of the invention. 

In the drawings: 

Fig. 1 is a schematic diagram representing a macro view of the system 
15 architecture showing the main modules of the system as well as access to the system; 

Fig. 2 is a schematic diagram representing the communication flow from the 
sales module of the system to the search/directory module; 

Fig. 3 is a schematic diagram representing the communication flow from the 
search directory module to the procurement module; 
20 Fig. 4 is a schematic diagram representing the communication flow between 

the sales module and the procurement module; 

Fig. 5 is a schematic diagram representing the general relationship among 
search parameters; 

Fig. 6 is a schematic diagram representing a generalisation of the direct stock 
25 procurement functions; 

Fig. 7 is a schematic diagram representing a generalisation of the indirect stock 
(non-stock) procurement functions; 

Fig. 8 is a schematic diagram representing the relationship among the different 
aspects of the sales module and the procurement module; 
30 Fig. 9 is a schematic diagram representing the relationship between the 

procurement module and the sales module in respect of the purchase/sales order 
processing functions; and, 

Fig. 10 is a schematic diagram representing a post-negotiation function of an 
embodiment of the invention. 
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Referring now to Fig 1, there is shown generally an embodiment of a system 1 
for facilitating e-commerce transactions. The system has three complementary 
components 2 to 4 that operate independently but co-operatively to streamline of the 
establishment, negotiation and execution of commercial transactions. Figs. 1-5 are 
schematic drawings representing an overview of these three complimentary 
components, the contents of which will be clearer in view of the description 
explanation of the respective components below. 

The described embodiment is particularly well suited to improving the 
efficiency with which complex international, intra-firm and domestic commercial 
transactions can be conducted. The three complementary components mentioned 
above and each in turn described in greater detail below, and are for the sake of 
convenience referred to as: 

• Macro/market search/directory 

• Micro/Sales module 

• Micro/Procurement module 

The first component, a macro/market search/directory module 2, provides a 
mechanism by which signals originating from separate enterprises are aggregated. The 
second component, a sales module 3 (supply-side communications module) is a 
mechanism by which each enterprise controls signals sent to both the macro/market 
module 2 and/or other enterprises' procurement module. The third component, the 
procurement module 4 is the mechanism by which the sales module signals can be 
captured from either the macro/market search/directory 2 or separate micro/sales 
modules 3. 

The three components provide the structure in which a business process 
activities can occur that includes: 

• product search/selection 

• negotiation 

• post-negotiation 

The first business process activity, product search/selection, involves an 
identification of prospective partners to a commercial transaction. The negotiation 
step facilitates the negotiation or bargaining between multiple parties as to the terms of 
a proposed commercial transaction. The post-negotiation function assists in the 
execution of the transaction management and logistical functions that are necessary to 
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be performed to execute any contract which is established between parties as a result 
of a successful outcome of the negotiation function. 

The inter-relationship between the configuration of the three components and 
the business process activities that occur within the system is important. The structural 
5 mechanics of the components provide the foundation of the model, and is designed in a 
manner to achieve a system-wide equilibrium by providing a balancing of dynamic 
forces (the second dimension condition), while simultaneously seeking to maximise 
the efficiency of the user and data inter-relationships in relation to 'user to system' and 
'user to user' contexts (the third, business process dimension condition). 
10 In practical terms, the equilibrium condition (at the most basic level) is 

satisfied by means of constructing the structure having the following mechanical 
characteristics: 

• open and decentralised entry and exit for all system actors 

• decentralised distribution of key sub-system data processing and 
15 management functions 

• instantaneous information and process data distribution mechanisms 

• dynamic exchange/adjustment mechanisms 

In the first respect, Figure 1 illustrates how, in broad terms, the system satisfies 
the open access requirement. The search/directory module 2 includes a 
20 search/directory component 5 together with a administration component 6 and a 
requisitions component 7. The functionality of at least part of the search/directory 
module 2 is provided by an Application Service Provider (ASP) connectable to the 
sales module 3 and procurement module 4 by a communications network, such as the 
Internet. 

25 The sales module 3 includes a catalogue/search requisition component 10, a 

registration component 11, a contract quotation component 12, a transport logistics 
services quote component 13, a negotiation component 14, a quote manager 
component 15, and sales order management and tracking component 16. An order 
communications component 17 and ERP communications component 18 enable 

30 communication between the sales module 3 and an enterprise resource planning (ERP) 
system 19 or like electronic data source. 

Similarly, the procurement module 4 includes a reverse tender/quotation 
component 30, a micro-chain external item data matching component 31, a non-stock 
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component 32, a stock component 33 and a purchase order management and tracking 
component 34. An order communications component 35 and ERP communications 
component 36 act to interconnect the procurement module 4 and a further ERP system 
37. 

5 The sales module 3 and procurement module 4 are realised by conventional 

computing apparatus and communication devices each including a processing unit and 
associated memory storage unit maintaining computer program code for causing the 
computing apparatus to execute the required functionality. 

In this example, each of the sales module 3 and the procurement module 4, and 
10 associated ERP systems, are located on the premises of separate selling and buying 
entities. In other embodiments, one or more of the entities may include both a sales 
module 3 and a procurement module 4 depending upon the commercial activities of 
that entity. 

All modules 2 to 4 of the system 1 interact with each other at a system 

15 component to system component level; ie., buy to sell, sell to buy, sell to market, 
market to sell, buy to market, market to buy. In that regard, each of the modules 2 to 4 
includes a communications gateway, respectively referenced 50 to 52, to facilitate 
communication between the modules 2 to 4. In addition, where a buyer or a seller 
does not possess software to permit module to module communication, buyers and 

20 seller can access each of the modules 2 to 4 via a standard Internet browser by use of 
browser access clients, respectively referenced 60 to 62. A browser access client can 
perform market/search, buy and sell functions by communicating directly with a 
particular component; ie., a market/search, buy or sell component. 

Figures 2-4 illustrate how the configuration of the system 1 encompasses the 

25 relationships that exist between the system's 'market-related' business process 
activities (the vertical firm to market business relationships) and the system's firm to 
firm business process activities (the horizontal firm to firm business process axis). The 
juxtaposition of the two provides the basis for the spatial relationships that occur 
between: 

30 • markets 

• industries 

• firms, and 

• products 
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at the three stages (search, negotiation and post-transaction management) in a 
commercial/transactional process. 

The configuration of these parameters encapsulate the fundamental business 
process relationships that make-up a 'virtual 'supply-chain'; i.e., the structure is 
5 capable of overcoming information asymmetries in order to seek and manage supplier- 
customer relationships among browser to system as well as system to system purchase 
and sale interactions. The practical implications of this are that a correct identification 
and control of these relationships permits the construction of electronic systems that 
are capable of generating predictable events resulting in expected and rational 
outcomes that are in dynamic equilibrium (optimal outcomes). 

Figure 2 illustrates the data flow from illustrative supply/sales modules 70 to 
72 to a market/search module -73. (Each entry in this figure also includes a 
procurement module, respectively 74 to 76, and an ERP system, respectively 77 to 79). 
This data flow represents a micro (1) to macro (many) data relationship. The data 
originates from each firm's enterprise resource planning (ERP) system 77 to 79 or 
other equivalent electronic data source. Each supply/sales module 70 to 72 selects 
appropriate data and converts that data into a content/form that can be used by the 
market/search module 73. 

This function provides the infrastructure for the market/search module 73 to 
receive firm derived supplier/product information including data updates/refresh on a 
regular basis. The data flow and content is determined by a sales module based data 
direction/control function, as will be explained below. 

The principle device that controls product/itemdata flow to the search/directory 
module 2 is situated in the sales module 3. The control issues relating to outbound 
data transmission turn upon solving for the broad parameters: 

• What data (ie., which product items) 

• Where that data is to be sent 

• How often 

Figures 3 and 4 illustrate how a firm's product/sales item information (what) is 
sent to two classes of receiver. Figure 3 shows data flowing to components having a 
one to many (1:M) data relationship, ie., search/directories and marketplaces. Figure 4 
shows data being transmitted directly to other firms being a one to one (1:1) data 
relationship. 
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The data transmission functions of each sales module 70 to 72 include 
controlling mechanisms that allow sellers to restrict the data content transmitted to 
different receivers. For example, sellers will wish to send a large number of their sales 
product items to marketplaces. By contrast, only selected items may wish to be 
5 transmitted to discrete buyers. 

Control issues include the frequency of catalogue updates and will vary 
according to destination type. Search/marketplace data updates may be required on a 
real-time basis because data will be viewed frequently by large numbers of viewers. 
On the other hand, product item updates sent to buyers (to refresh their supply-chain 
10 catalogues), will be much more restricted in scope. 

Figure 3 is an extension of Figure 2 and illustrates the movement of discrete 
data from the search/marketplace 73 to the buyer's modules 74 to 76. The purpose of 
this function is to provide a data saving mechanism whereby a prospective buyer can 
build a customised catalogue of numerous items selected from a search/marketplace 
15 module 2. 

Figure 4 also illustrates the transmission flow of an electronic transportation 
function. The transportation function involves the movement of a buyer from a 
search/marketplace module to a discrete firm's sales module. For example, upon 
selecting an item listed in the marketplace directory module 2, a buyer that wishes to 

20 purchase the item(s) can elect to be transported (with data content) to a sales module. 
The data content that is transported with the buyer is derived from products it has 
located in the marketplace/directory and appropriated to electronic requisitions. 

As the buyer may be looking at products from more than one seller, this may 
require the creation of multiple simultaneous requisitions. Therefore, simultaneous 

25 transport to multiple sales modules of different seller is possible. 

Both the procurement and search/marketplace modules make use of the search 
module 2 to provide a buyer with functionality that assists it in making a selection 
decision. The primary search mechanism of the search module 2 is the 
search/directory component 5, which is designed to select, group and list search results 

30 according to a user-selected configuration of industry index, product classification, 
company/firm and geographical locator codes. All of the generic (non-product or firm 
specific variables) indices and coding systems used are derived from standard indices 
recognised and administered by the United Nations Statistical Data Division and 
private and public statistical agencies. 
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The search/directory component 5 functions by searching mandatory and 
optional parameters which the user must specify/select in defining the search criteria. 
The search/directory component 5 configures the user's selection mandatory and 
optional search criteria. It produces a simple algorithm that formats the breadth of the 
5 search to conform to the governing algorithm. 



The search process functions by having the cross-relational algorithm link 
classes of information. Some of the classes correspond to an existing indexing system, 
other data classes do not. The data classes and corresponding indices are as follows: 



Data Class 


Index 


Industry (Broad) 


TOT /"I /r\ J* • i 1 i\ 

ISIC (2 digit level) 


Product 




-goods 


HS (4,6,10 digit level) 


-services 


CPC (3,5 digit level) 


Brand 




Company Name 




-parent 




-subsidary 




Region 


13 Category Region Code 


Country 


UN 2 alpha code 


State/Province 


UN intra-country code 


ISDN-telephone area code 


Internat. ISDN code 


Port- Air/Sea/Inland 


UN Port Codes 



10 Each specific product or service entered into the directory will have a separate 

and unique identifier tag that is derived from the configuration algorithm. The search 
configuration algorithm distinguishes between companies, products and brands having 
the same or similar attributes by arranging the relationships between attributes of the 
governing classes. 

15 For example; numerous similar products (good or service) may fall within the 

same CPC or HS classification categories. Each particular product item listed in the 
directory will inherit a unique identifier tag that it derives from the totality of the 
classification attributes listed in the table above. Even if a product is tagged to a 
particular manufacturing or service providing enterprise operating across several 
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distribution points, the same product offered across multiple outlets will take on an 
unique identifier tag for each sale unit. 

Accordingly, in order to identify the precise origin of a product, geographical 
location identifiers can be attached to the product. These can be further cross- 
5 referenced to other important geographical identifiers such as nearest ports, airports or 
distribution hubs all identified by their respective international/domestic classification 
codes. 

Figure 5 illustrates how the search mechanism of the search/directory module 5 
drills down across four levels of organisational form, namely, Industry 80, Product 81, 

10 Company 82, and Brand 83. 

The cross-relational attributes of the item identifier criteria means that items 
can be gathered together at various levels of aggregation and disaggregation. Users 
can therefore enter the system and search either by broad product descriptors 84, 
industry classification, brand 83, firm 85 or location 86 or any combination of these 

15 fields. It is therefore possible for the search mechanism to generate directories and 
lists by any of these descriptors and classifications. 

Moreover these lists or directories can be reported either by location, firm, 
brand and or industry. In addition cross-comparison of products is straight-forward. 
Having generated the list of products in the appropriate catalogue, all the information 

20 about the products can be readily compared, including reserve price, volume, product 
characteristics and specifications. 

Internet search engines cannot by their very nature perform searches which are 
able to most accurately and expediently identify prospective commercial trading 
partners - either sellers and buyers. At present most organizations will conduct 

25 searches having a particular type or class of product in mind. Given the number of 
different types of information and products that may fall within the scope of a general 
search term, an organisation conducting a search for prospective business partners 
typically ends up wasting a great deal of time sifting and sorting among relevant and 
irrelevant search results. 

30 The search/directory module 2 provides the ability to narrow the scope of the 

search considerably using a mechanism that is capable of reducing the search criteria 
to a level of specificity that accurately reflects the product being searched, and 
subsequently ranking these result criteria. 
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To improve this level of specificity a more precise means of conducting a 
product search is required for having a high degree of precision is by means of a search 
mechanism that conducts a database search for business enterprises that sell products 
falling into a product's appropriate Harmonised Tariff Classification (HTC) Code. 
5 The HTC system is a classification index that is internationally recognised and 

used by customs authorities around the world for the classification of outgoing and 
incoming goods crossing international or national borders. 
The HTC System operates as follows: 

4 digits : represent the specific industry 

10 +2 digits : represent 6 broad product class 

+2 digits : represent 8 specific product class 

+2 digits : represent 10 specific products 

The search/directory module 2 provides prospective buyers with the ability to 
look up the HTC Code corresponding to the product type (general or specific) of the 
15 product they wish to search. Each database search by HTC Code is cross-referenced to 
industry level. For example, the Standard International Trade Classification system 
(SITC) and business enterprise name criteria enables the searcher to further narrow the 
search criteria. Conversely, all searches by business enterprise name or general product 
description will be cross-reference to the HTC Code. Therefore, the common search 
20 criteria of all products contained in the product search database are each product's 
discrete HTC Code. Thus we will build the first product search engine based upon the 
HTC Code. 

The search/directory module 2 uses the HTC system as well as other overlaying 
parameters built into the search mechanism, thus creating increased levels of 
25 functionality and dynamism. The results are to be categorised by a ranking system 
based upon preferential outcomes selected by the user. 

The search/directory module 2 is preferably case sensitive and requires at least 
one field to contain data before the search can be activated. Once the search criteria 
are completed the user ranks the search numerically. This ranking of search 
30 parameters creates dynamic outcomes not available with current search mechanisms. 
A cross referencing mechanism matches procurement requirements with search items 
based on product type, price, volume, payment terms, geographical location 

Additional flexibility may be built into this search mechanism whereby no 
fields require mandatory inputs. Additional fields can be nominated/included at the 
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time of the search to create a increased spectrum of result criteria. This increased level 
of dynamism with the search provides for the user the optimum outcome. This may 
result in unexpected outcomes based upon expected values. 

The greater the specificity of the search criteria ultimately provides expanded 
5 search results generated from the flexibility created from within the search mechanism. 

The search function can be supplemented by expert system functionality able to 
categorise and rank search outcomes according to the user's preferences. 

The procurement module 4 is a processing mechanism that handles the 
demand-oriented procurement requirements of a single firm. It matches the firm's 
10 demand requirements with product and service items that it must obtain from sources 
external to the firm. The search/directory functions of the search/directory module 2, 
operating in conjunction with procurement module functions of the procurement 
module 4, provides the specific sources of products and services that the firm can 
procure. 

15 Procurement items are obtained from three sources of supply within the system: 

• Items saved from the marketplace/directory searches 

• Items saved from sales modules searches or transmission 

• Items entered directly into the procurement module by non-system browser 
access clients 

20 These three external sources of items provide the pool (supply) of potential 

items for purchase by the firm that may be used to satisfy the demand requirements of 
the firm. 

However, a firm's procurement requirements are derived from factors internal 
to the firm arising from its operating and production activities. The procurement 

25 module 4 distinguishes between two broad types of procurement requirements, namely 
stock items and non-stock items, respectively handled by the stock component 33 and 
the non-stock component 32. 

Stock item requisitions are made as a result of the depletion of product items 
(inventory) that a firm uses direct result its manufacturing or production activities; ie., 

30 are items that are transformed and/or undergo a value-adding process in the course of 
producing another product. Non-stock items are products that a firm consumes as an 
indirect result of its daily activities. Non-stock items include maintenance, repair and 
overhead (MRO) items such as stationary, computer support items etc. 
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In addition, the procurement module 4 handles two broad types of purchase 

orders: 

• Blanket (or standing) purchase orders 

• One-off (or standard) purchase orders 

5 The procurement module 4 coordinates the firm's internal demand 

requirements and provides a mechanism by which these internal demand requirements 
can be matched with the externally acquired pool of required items. 

Figure 6 is a diagram of the general process flow of the direct stock 
procurement process. The demand for stock items is derived at step 100 from 
10 processes that occur within a firm's back-office systems (usually an ERP system 101). 
The ERP contains a list of direct-stock product items and indicates when stock must 
be replenished. The procurement module 4 functions by matching the firm's direct- 
stock product item requirements with: 

• items supplied by current suppliers 
15 • items supplied by potential suppliers 

The method and source of the matching process depends upon whether 

• an existing blanket purchase order is to be extended 

• a new blanket purchase order is to be created 

• a one-off purchase order is to be created 

20 Additional functionality permits the procurement requisition to be fulfilled to 

conform to business process requirements as to whether: 

• a quotation price is required 

• a tender process must be followed 

• and whereby inbound quotes and tenders are determined on the basis of a 
25 dynamic, reverse negotiating process. 

The supply of stock items is derived from the three external sources identified 
above. The method of matching is dependant upon the business process functions 
which are required to be met under the particular circumstances of the specific 
procurement requirements. Once the purchase order is made at step 102, sent and 
30 confirmed by suppliers 103 and 104, its confirmation is processed back into the ERP 
system 100. 

Figure 7 is a diagram of the general process flow of the indirect or non-stock 
procurement process. The demand for non-stock items is derived from processes that 
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occur as a result of consumption as a result of organizational and operational factors 
within a firm. It is frequently the case that inventory management of consumption of 
non-stock items are not as sensitive and accurate as is the case with stock-items. The 
demand for non-stock items is derived from specific operating units 110 to 112 within 
5 the firm. The list of non-stock product items within the ERP 101 is generalized to 
product type and category rather than at a highly specific level as it is with stock items. 

Demand for non-stock items is derived from members of the firm who 
recognize replenishment is required. Requisition of non-stock items is usuall initiated 
by the member rather than the ERP or back-office functions (but is may be the case 
that the ERP initiates some purchase requirements). 

The procurement module 4 provides a mechanism by which a non-stock 
requisition can be created at step 113 by the initiating member. The requisition is 
formed according to the results of a matching of the requisition product item 
requirements with: 

• items supplied by current suppliers 

• items supplied by potential suppliers 
Additional functionality permits the procurement requisition to be fulfilled to conform 
to business process requirements as to whether: 

• a quotation price is required 

• a tender process must be followed 

• and whereby inbound quotes and tenders are determined on the basis of a 
dynamic, reverse negotiating process. 

The supply of non-stock items is derived from the three external sources 
identified above. The method of matching is dependant upon the business process 
functions which are required to be met under the particular circumstances of the 
specific procurement requirements. 

Once the purchase order is made, sent and confirmed by the supplier, its 
confirmation is processed back into the ERP (back-office) systems. 

Figure 8 is a diagram illustrating the operation of the sales module 3 shown in 
Figure 1. The sales module 3 is a device that performs supply-side functions that 
either 'stand-alone' to configure and execute a sales transaction; or function in concert 
with a procurement module to provide an increased level of automated transaction 
processing. A buyer can be transported to the sales module 3 via the transportation 
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mechanism from a search/directory module 2 or procurement module 4; alternatively, 
a buyer can enter the sales module via direct browser access. 

In all cases, the buyer-client selects a list of items according to a series of 
business case rules or navigational choices and creates a product requisition form. The 
5 item selection process will, by implication, generate a list of items that the buyer-client 
configures according to its requirements. If transported from a procurement module 4 
or search/directory module 2, the buyer will have a partially configured a requisition. 
The requisition contains data to be used for the purposes of obtaining a quotation, 
demonstration order or outright purchase (negotiation). 

10 The item selection list, by implication, is the same data that will be contained in 

a sales order invoice. The sales order is the configuration of data that will be 
processed as the final sales terms and conditions between the buyer and seller. The 
sales order is also processed in the ERP as a discrete transactional outcome. 

The population of item data within the sales module is derived directly from 

15 data obtained from the ERP (thus avoiding data duplication). 

Upon completing a requisition, a registration process must occur before the 
buyer can proceed with the transaction. If the buyer has been transported from a 
procurement or search/directory module, registration is automatic. The registration 
data is matched to customer/sales related data in the seller-firm's ERP consistent with, 

20 and to be used for, customer relations management (CRM) functions/purposes. 

At this stage, the requisition is made according to an unadjusted order price. 
This is the base price upon which further price-related adjustments will be made 
subject to the functions described below. A provisional sales order number is allocated 
to the requisition (now becoming a provisional sales order). 

25 The provisional sales order is provisional for several reasons. One reason is 

that its initial purpose is derived from that fact that the buyer-client may wish to obtain 
a quotation only. The seller's quotation price must be competitive, but not be the last 
price-related say; ie., further price adjustments may be made at a later step in the 
process; ie., final negotiation. 

30 At the quotation stage system generated adjustments for: 

• volume purchases (ERP data) 

• customer status discounts- ie., if the customer is known and good- a 
discount may apply 
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The system computes the quotation price by taking the unadjusted provisional 
sales order price and then deducting appropriate rebates. 

No price adjustment is mandatory- only occurs if volume and customer class 
rebates apply. The system computes the quotation price. A quotation number is 
5 generated by the system and the provisional sales order is stored in the system under 
the system assigned quotation number. 

The buyer is provided with the quotation number and the quotation details and 
the quotation amount. The should be able to leave and access the system calling up the 
provisional sales order at a later time by inputting a password and sales order number. 
10 The buyer may, before or after viewing the quote, change their mind and wish 

to re-configure their order. Functionality allowing the buyer to add/delete items in the 
sales order list is provided. 

If a buyer selects a request for quotation, a second, parallel, quotation function 
is set in motion being a quotation for ancillary service contracts such as 
15 transport/logistics, insurance, finance and inspection. 

The services contract quotations are calculated using system data derived from 
the core sales contract plus: 

• shipment details, including price, etc. 

• cargo type 

20 • cargo weight and volume data, etc, 

The sales module automatically determines whether the sales contract is 
domestic or international by conducting a cross-check between country of origin (ie., 
seller's location) and country of destination. 

The buyer (or ERP) will fill in the additional required information. 
25 • Place of loading (domestic) 

• Place of discharge (domestic) 

• Port of loading (international) 

• Port of discharge (international) 

• Inland freight required from port to plant (if sea or air) 
30 • Container type- general or refrigerated (if sea) 

• Estimated time of departure (ERP lead-time + one week) 
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The buyer will check the information and select the send quote to shipping 
agent or forwarder. The shipping agent will be sent an email notifying him that a new 
RFQ has been posted to his URL/access site. 

The vast majority of international and domestic commercial transactions 
5 undertaken between business entities (B2B transactions) fall into the category of 
intermediate goods trade. Intermediate goods trade refers to B2B trade of primary, or 
secondary non-finished goods requiring further processing to create a marketable 
finished product. 

International and domestic intermediate goods trade is dominated by the 
10 pricing decision. The pricing-decision is the core decision of the transaction process. 
It involves a price-setting decision on the part of the seller, and a price-bidding 
decision on the part of the buyer. The ultimate buyer will undertake a comparative and 
competitive market analysis and, subsequently, make a conscious and calculated 
pricing decision. A seller, on the other hand, will set an indicative price, which, under 
15 typical circumstances is broadly calculated on a cost plus profit basis. The price 
spread between the seller's preferred selling price and the buyer's offer price is the 
negotiable margin. 

However, in addition to price, intermediate goods transactions are frequently 
complex and additional factors are part of any transaction. These factors include, for 
20 example: 

• volume 

• the method of payment, ie, 

pre-payment 
letter of credit 
25 - documentary collections 

open account; 

• credit terms; ie, 

30, 60, 90, 120, 180 or more days 

• credit rates of interest 

30 • transport and logistics charges 

• insurance charges 

• inspection charges 

• banking and finance related charges 
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• country and credit risk adjustments 

In an international trade negotiation buyers and sellers effectively negotiate a 
transaction involving multiple factors, which generally include the following variables, 
though may include several others: 
5 • Price 

• Volume 

• Payment Method 

• Time terms 

• Credit terms 

10 Additional negotiating terms can be either added or excluded from the negotiation 
depending on whether the transaction is an international, domestic or intra-firm 
(international or domestic) negotiation. The transaction embodiment provides the 
ability to negotiate over a range of variables. It operates in real-time and is capable of 
being used by multiple users simultaneously. All functions are conducted in a 

15 systematic manner that is consistent with the well-known international standards 
Incoterms 2000 and the CP 500 requirements. 

The system 1 provides a mechanism by which buyers and sellers can negotiate 
an agreed set of contractual outcomes covering price and all price-related aspects of 
the contract. 

20 A feature of the system 1 is that it can operate at three levels: 

• As a multi-buyer and/or multi seller multiparametric auction 

• As a single buyer to single seller multiparametric negotiation game. 

• As a simultaneous combination of the multiparametric auction and the 
multiparametric negotiation game. 

25 The auction aspect of the system 1 may use any one of the standard auction 

design rules, which will be chosen by the seller in advance. For instance the seller 
may choose to sell the product using the rules of any one of the "English" auction, the 
"Dutch" auction, the "sealed-bid" auction or the "Vickrey" auction. The type of 
auction will be chosen by the seller and communicated to the buyers in advance. 

30 However, the major original method by which the auction is instigated in the 
transaction hub comes from the method by which sell offers and buy bids are entered 
and resolved and the number of variables included in the auction process, 
(a) Setting the Seller's Reserve Offer 
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In order for the system 1 to begin to perform its operations, the seller specifies values 
for the relevant trading parameters over which it has influence in an international trade 
negotiation. In an international trade transaction the seller is not only interested in 
price, but also the following additional variables: volume; payment method; time 
5 terms; and credit terms (as well as, perhaps, several others). 

For example, a seller may be prepared to accept a lower price if the seller can 
sell a greater volume or get more favourable payment terms. Therefore, it is usual for 
a seller, during the course of a negotiation, to make expected value calculations over a 
wide range of different combinations of these variables. The system 1 provides an 

10 automated process of preference calculation by allowing sellers to transparently reveal 
to themselves the values placed on the various components of any offer and then to 
verify that their preference ordering is consistent and non-reflexive. 

In determining the final outcome of the negotiation, it is possible that the 
computer optimising algorithm used in the system 1 will generate a combination of 

15 price, payment methods, credit terms, credit rates of interest etc that was not be 
anticipated or thought of by the human being who sets the parameter values for the sell 
offer. Because there are many thousands of possible combinations and permutations, a 
partly or completely non-reflexive preference ordering over all preferences may be 
generated. The seller (with the aid of the computer) identifies all those possible 

20 combinations of the parameter values that are of equal expected value, most 
particularly those covering the reserve offer. That is, once the seller has chosen one 
combination of parameter values that represent the preferred reserve offer (Oi ), the 
seller should then be able to identify readily other parameter values that generate an 
identical expected value calculation such that a second reserve offer (0 2 )> third reserve 

25 offer (0 3 ), and other reserve offers are of equivalent value? 

Step 1: 

Seller enters values for all variables of its most preferred reserve offer (Oi). 
This is the offer that the seller would be happy to accept if it were offered by any 
30 buyer. 

The seller is required to enter a value for each of the following, where they 

apply: 

• price 
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• volume and volume price reductions, where they apply 

• the method of payment, ie, 

pre-payment 
letter of credit 
5 - documentary collections 

open account; 

• credit terms; ie, 

30, 60, 90, 120, 180 or more days 

• credit rates of interest 

10 • transport and logistics charges 

• insurance charges 

• inspection charges 

• banking and finance related charges 

• country and credit risk adjustments 

15 As part of this initial value setting, the seller indicates the precise fractional 
relationship between the change in price and change in each of the variables that 
directly (in either a linear or non-linear relationship) affect the determination of price: 

• volume; 

The seller indicates the percentage volume discount on price for a range 
20 of different volumes, all other variables held constant (this will generate a 

simple linear or non-linear function of price change as a function of volume) 

• method of payment; 

The seller indicates the percentage price increase, from the base price, 
contained in Oi, associated with each payment method beyond pre-payment 
25 such as letter of credit, documentary collections open account, all other 

variables held constant (this will generate a linear or non-linear function of 
price change as a function of payment method) 

• credit terms; 

The seller indicates the percentage increase in price associated with the 
30 increase of time beyond 0 days such as 30, 60, 90, 120, 180 or more days, all 

■other variables held constant (this will generate a simple linear or non-linear 
function of price change as a function of time terms) 

• credit rates of interest; 
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The seller indicates the percentage increase in price associated with 
interest penalties over time, all other variables held constant (this will generate 
a simple linear or non-linear function of price change as a function of interest 
premiums). 

5 The system 1 then determines an expected value for this sell offer, say vi. At 

the conclusion of step 1 the seller has specified information on the preferred reserve 
offer and the way important price-related variables such as volume and method of 
payment impact upon price change. With this revealed preference information, the 
system 1 is able to generate all possible combinations of the parameters that will 
10 generate offers of equal expected value using a standard maximum likelihood 
algorithm. 
Step 2: 

The system 1 now gives the seller a chance to check revealed preferences by allowing 
the seller to enters values for all relevant variables, but with a slightly higher price and 

15 altered values, where relevant, for other terms, say for example less favourable 
payment terms, representing an alternative offer, (0 2 ) which is identical in expected 
value to vi=Oi=0 2 . Importantly this offer is considered to be of equal value in the 
sense that the seller is no worse off than in the case of Oi. 

Using the maximum likelihood algorithm the computer is able to check the new 

20 values against the preferences revealed in Step 1 for consistency. The system 1 will 
indicate to the seller if there are any inconsistencies and allow the seller the chance to 
correct inconsistent values. After repeating this exercise a small number of times, the 
computer maximum likelihood algorithm will generate a complete set of non-reflexive 
preference orderings. 

25 Step 3: 

Seller now repeats Step 2 and enters values for all relevant variables, but with a 
slightly higher price and altered values for other terms representing an alternative 
offer, (0 3 ) which is identical in expected value to vi=Oi=0 2 =0 3 . 

Once this process is completed, the seller has effectively established a system 
30 of functional relationships between variations in a key trading perameter and one or 
more other trading parameters which may be represented as a system of simultaneous 
equations whereby price is a function of a range of variables and changes in price are 
functions of a range of other, but related variables. Using any one of a number of 
standard maximum likelihood techniques such as Newton-Raphson or the Genetic 
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algorithm parameter approach, a matrix of equivalent value calculations can be 
generated for every possible permutation or combination of the variables included in 
the sell offer process. This means that the complete equivalence of value will be 
revealed for every possible combination of price and the various other terms identified 
5 above as part of this reserve offer calculation. 

At the end of this process we have a complete set of seller offers Oi,...O n , 
covering all possible combinations of the trade variables that generate offers that are 
equivalent in value, Vi. This means that it is relatively straight forward by essentially 
interpolating between Oi,...O n in a multi-dimensional space, to compare any bid from 
10 any buyer and determine whether it is above the seller's reserve offer, v 2 > vi, or below 
the reserve offer, v 2 < Vi, irrespective of the composition of the offer. 
Example 

Consider a simple hypothetical example. Assume that a seller enters initial 
values for the preferred reserve offer which include a price of $10 per unit, to be paid 

15 by letter of credit on 60 days at an effective credit rate of interest of 10%. As part of 
the initial value setting the seller also indicates the percentage price increase required if 
the payment method is not letter of credit but rather documentary collections or open 
account, or if the payment is by letter of credit but on less favourable time terms such 
as 90 days. With this revealed information the system 1, using a maximum likelihood 

20 estimator, is able to identify other equivalent reserve offers which, for example, might 
be a price of $11 per unit by letter of credit on 90 days at an effective interest rate of 
12%. In other words the computer is able to determine different combinations of price, 
payment method, time terms etc that are of equivalent value to the seller's initial 
reserve offer and all combinations of the variables that are superior and inferior to the 

25 reserve offer. 

Once the seller has completed the exercise of determining its reserve offers, the 
seller may now choose to indicate that it has product to offer for auction, or sale and 
may begin negotiating directly with a potential buyer, or do both. 
The Single Seller Auction Scenario 
30 Having specified that it is has product to sell and it wishes to proceed with an 

auction, the seller now posts this information to the product catalogue. 
Step 1: Seller indicates the type of auction and auction rules 
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The seller may choose to sell the product using any of the "English" auction, 
the "Dutch" auction, the "sealed-bid" auction or the "Vickrey" auction rules. 
Step 2: Bids come in from Buyers 

The auction remains open for a specified time or until there is a bid of value v n 
5 > vi. In the same way that the seller specifies values for the variables: volume; 
Payment Method; Time terms; and Credit terms, etc., the buyer must also enter a bid 
that indicates values for each of the relevant terms to an international transaction. 
Depending upon the rules of the auction, certain information will be revealed to all 
market participants. However, as each unsuccessful bid comes in, the owner of that 
10 bid will receive feedback about their bid and what they might change, or increase in 
order to make the bid closer to the reserve offer of the seller. For example a buyer 
might receive advice to either reduce time terms from say 90 days to 60 days or 
slightly increase price or some combination of the two. 

Note, the reserve offer of the seller is not revealed to the bidders. At the end of 
15 this process, the product will be sold to the highest bidder measured by the extent to 
which the winning bid exceeds the reserve offer. Where there are two identical 
winning bids the bid received first will be the successful bid. or the market did not 
clear. When the market does not clear then the seller has the choice of beginning the 
process over again or, alternatively, to begin negotiating directly with one or more of 
20 the potential buyers. 

The Single Seller-Single Buyer Negotiation Scenario 

In many real world trade situations the buyer and seller are well known to each 
other and often have a long-standing trading relationship. In these cases they may 
wish to begin to negotiate directly with each other. The system 1 designed to deal with 
25 just such situations. In this sense the system 1 provides the mechanism to undertake a 
bilateral bargaining game. The bilateral bargaining game may take one of several 
forms and again the rules covering the negotiation would be agreed in advance of the 
formal commencement of the bargain. Importantly, in the bargaining 
games/negotiation scenario, the buyer may reveal bids in a manner similar to the way 
30 the seller reveals preferences. In the transaction hub the bargaining/negotiation game 
may take one of the following forms: 

• an alternating-offer bargaining game instigated by the buyer (requiring real 
time on-line access by both buyer and seller) 
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• an alternating-offer bargaining game instigated by the seller (requiring real 
time on-line access by both buyer and seller) 

• a single-offer bargaining game instigated by the buyer (requiring real time 
on-line access by the seller only) 

5 • a single-offer bargaining game instigated by the seller (requiring real time 

on-line access by the buyer only) 

• a cooperative game instigated by either party and with an agreed arbitrator 
(the transaction hub via the computer itself). 

In these bargaining games, an international trade transaction operates by means 
10 of a multiparametric negotiation, as explained above. The bargaining is not constrained 
to a single variable, price, but rather embraces all the variables relevant to an 
international trade transaction. In this case, though, the bargaining framework 
involves a cooperative game instigated by either party and with an agreed arbitrator, 
whereas the transaction hub is both the vehicle through which the negotiation occurs 
15 and the arbitrator to the negotiation. 

In the bargaining/negotiation games buyers and sellers can negotiate over the 
whole range of international trade terms identified above. The process may begin with 
either the seller, who has set the reserve offers Oi to O n with equivalent value, v 1? or 
with the buyer, who undertakes a similar process to the seller, in order to specify 
20 maximum bids, Bj to B n with equivalent value, v k beyond which the buyer is not 
prepared to go. As long as v k > Vi then a bargain can occur and there is room for 
negotiation. 

Where v k > Vi then a bargain/negotiation may take place and the computer will 
feed back to both sides the need to change values. For example, hypothetically, the 
25 computer may indicate to the seller to slightly lower price and the buyer to slightly 
improve payment time terms from say 90 days to 60 days. That is, the 

The buyer and seller may bargain themselves, with advice from the computer, 
or let the transaction hub assist them to come up with a satisfactory solution that is at 
least no worse than the outcome they would have achieved bargaining on their own, 
30 and most likely to be more favourable to both parties, all other things held equal. 

In order to assist in the arbitration process, the seller and the buyer each reveal 
some additional information relating to the terms over which they are negotiating. 
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Both the seller and buyer will each have to allocate simple arithmetic weights 
to each of the terms over which they are negotiating. Consider the following simple 
example: 



Price 


Payment 
Method 


Credit Time 
Terms 


Interest Terms 


X 


A 


b 


c 


D 


1 



5 The weights a + b + c + d= l. This information, plus the information revealed 

by the seller and buyer when specifying their respective pricing functions will be used 
by the system 1, using a genetic algorithm parameter framework, to find the most 
favourable outcome over price and all related terms to the negotiation. It is possible 
for there to be more than one outcome. Where there are several outcomes of 
10 equivalent expected value then the computer will choose one at random. 

Once the system 1 has been in use for some time and has built up a profile of 
previous successful transactions this information can be interrogated to assist in 
facilitating further successful transactions. Desirably, neural network functionality is 
used to augment the optimisation process. 
15 It will also be possible for the seller to undertake both an auction and a 

negotiation simultaneously, and to undertake multiple negotiations simultaneously. 
Post-Negotiation Transaction Processing 
Direct Purchase and Sales Order Processing 

This section describes the process flow and data specifications for the 
20 configuration and transmission of purchase order and corresponding sales order data 
between a buyer's procurement and seller's sales modules. 

These functions originate from mechanisms contained within the procurement 
module 4 and sales module 3. After a purchase order (PO) draw-down (for a one-off or 
blanket purchase order (BPO)) has occurred within the ERP 37 (or is manually 
25 interfaced), the PO details appear in the procurement module 4 ready for processing. 
This outbound PO is to be delivered from the originating procurement to the 
appropriate sales module. 

The procurement module 4 recognizes and distinguishes between outbound 
PO's to be delivered to suppliers that do not have a sales module as well as outbound 
30 PO's to be delivered to a sales module. 
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The buy-side administrator will receive the PO (in the normal course of events, 
which will appear in the buy-side outbound PO interface). The administrator will 
check the order (ie., requisitioned items) and seller details. If all appear to be correct 
and no critical data has been omitted from the order, the administrator selects the 
5 'process order' function. 

The 'process order' function will activate a process whereby the PO data will 
then be transmitted to the appropriate sell-side platform where it will be received and 
processed (on the sell-side platform) in a manner described below. 

The sales module 3 contains functionality that enables the receipt of inbound 
10 purchase orders in the form of inbound sales-order administration functions. Inbound 
PO's (ie., on the sell-side) are presented to the system administrator via the inbound 
sales order screen. The system administrator performs an order approval process. The 
sell-side administrator checks the order details and seller details. If all appear to be 
correct and no critical data has been omitted from the order, the administrator selects 
15 the 'process order' function. If the order appears to be correct, it can be processed to 
the ERP. A sales order confirmation will then be transmitted back to the buyer . 

The confirmation will be communicated back to the buyer as an order status 
code. For example; 

• accepted orders= status code 1 
20 • amended orders= status code 2 

• rejected orders= status code 3 

If the order is not accepted, the functionality below will be required. In some 
circumstances, the seller may not be able to fulfill the order as presented. The 
seller/administrator has two options: 
25 • amend the order 

• reject the order 

Functionality to permit the seller/administrator to change/amend the volume 
requested by the buyer in the original PO is provided. The seller/administrator will 
select the 'amend order' button. Selection will enable the volume field to be changed. 
30 If the order volume is changed, the amended order volume change must be 
communicated back to the buyer's procurement module. 
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The data, therefore to be communicated back to the buyer's procurement 
module is the changed volume and status code 2 data. Once received by the buyer, 
existing functionality already contained in the buy-side system is activated. 

If the order is to be rejected, the seller/administrator will select the 'reject 
5 order' button. Selection will terminate the transaction. This is communicated back to 
the buyer. 

The data flows inherent in the order rejection function are straight-forward. It 
requires that the appropriate status code; ie., 3, be transmitted back to the buyer's 
procurement module. 

10 Messages back to the buyer's procurement module 4 appear as inbound PO 

confirmation functions. An order that has been accepted by a sales module is 
communicated back to a procurement module as an order having a status code= 1, 
being a straight acceptance. The buy-side administrator can view the order details and 
then proceed with the 'process order' function which will process the order back into 

15 the buyer's ERP 37. 

An amended order will be communicated back to the procurement module as: 

• a status code 2 and 

• including the amended volume data 

The amended order is communicated to the buyer/administrator in the buyer-side 
20 'inbound notifications' screen as an 'amended purchase order' in the 'inbound 
notifications' interface of the procurement module. The buy-side administrator can 
view the order details: 

• proceed with the 'process order' function (which will process the order 
back into the buyer's ERP), or; 

25 • terminate the order (and begin conventional non-online discussions with 

supplier- this may involve breach of contract at this stage and require manual 
intervention. 

A rejected order will be communicated back to the buy-side platform as a 
status code 3 rejection. The rejected order is communicated to the buyer/administrator 
30 via the buyer-side 'inbound notifications' screen as a 'a rejected purchase order'. 

• This will constitute a breach of contract and require manual intervention. 
Post-negotiation 
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In the post negotiation phase of the transaction, as illustrated in Figure 10 various 
ancillary transaction pre-conditions and requirements must be satisfied before the core 
contract is executed. Negotiated contract requirements must be co-ordinated and 
performed before the movement of goods can occur. 
5 The core contract has terms and conditions negotiated between the parties to a 

sales contract. These may include: 

• parties to the contract, 

• description of the goods, 

• volume 
10 • price 

• payment terms 

The terms upon which payment is to be made from the buyer to the seller is the 
link between the core contract and several related contracts are likely to be made with 
third parties. Although these related sub-contracts facilitate the ultimate execution of 
15 the core contract, this core contract is of course executed according to the payment 
terms specified in the core contract. In essence, proper execution of the sub-contracts 
effectively act as "conditions" to the core contract, and must be satisfied by the 
appropriate party. 

These appropriate parties are respectively involved in various post-negotiation 
20 functions. These include: 

• transport and shipping 

• insurance 

• inspection 

• credit and banking 

25 In a mechanistic sense, if the satisfaction of the core conditions which 

correspond to each of the sub-contracts is incorporated within an automated business 
process in a logical manner, the sequential satisfaction of the sub-contracts can be 
viewed as a lock-and-key mechanism. This sequence can be formatted in a manner to 
ensure that the automated process does not occur without the proper checks and 

30 balances having taken place. 

The lock and key logic underlying the automation of the post-transaction 
consolidation process is also critical to establishing the precise point at which the risk 
of loss, ownership title and payment obligations pass from the seller to the buyer. 
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Taken one step further this is also the precise point in the automation process at 
which a direct interface with external "digital" banking systems can be established and, 
in accordance with contractual terms, instructions to shift funds from the buyer to the 
seller can occur. 

5 Finally, the above also implies that it is this point in the business process at 

which financial data can be allocated within the business process back into the buyer 
and seller's internal financial management and accounting systems. 

Prior to the negotiation, the buyer inputs information relating to its identity. In 
addition, by selecting a product, key product information is identified by the system 
10 relating to the precise identification and description of the goods the buyer wishes to 
purchase. At the conclusion of the transaction negotiation, offers submitted by the 
buyer will be either rejected or accepted by the program. An offer that is accepted by 
the program will contain all the core terms of the sales contract being: 

• identities of the parties to the contract 

15 • identification of the subject matter of the contract 

• price, volume and payment terms 

This information will be consolidated and form the content of a proforma 
Invoice which the seller sends to the buyer to confirm receipt of the order and 
acceptance of the terms offered. All data is already stored or generated within the 
20 system. 

At this point in the process, the core contract is concluded and the influence of 
the several sub-contracts (mentioned above) come into play. 

As mentioned above, each of the sub-contracts performs an important role and 
functions as "conditions" which must be satisfied in the course of executing the terms 
25 of the core contract. 

In order to automate and coordinate the sequencing of pre-shipment contractual 
requirements, embodiments of the invention involve a post-transaction processing 
mechanism. The described embodiment coordinates, integrates and sequences the 
consolidation, generation and respective submission of a purchase order by the buyer 
30 to the seller, and the issue of an invoice from the seller to the buyer. 

Under the rules of commercial trade (such as Incoterms 1990 and 2000 and the 
UCP 500), these conditions can also be arranged in a sequential fashion. If these 
conditions are automated within a process the proceeds in a stepwise fashion, the entire 
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post-transaction execution process can be logically and systematically managed over 
time. 

Unlike the transaction negotiation that can occur instantaneously, a time 
element is introduced into the post-transaction management functions. Each of the 
5 conditions can be configured such that, in a stepwise fashion, the proper satisfaction of 
each condition over time ensures that the core contract conditions are recognised as 
having been systematically satisfied by the system. 

A post-transaction management system assists the user to monitor the progress 
of the functions as they are entered or activated within the system. 
10 The post-negotiation process incorporates coordination functions that are 

governed by: 

• the estimated time of departure (shipment of the product from the 
contracted port or point of loading/shipment) 

• logistical aspects of the transaction must be coordinated with the execution 
15 of agreed financing terms based on Incoterms 2000 and/or UCP 500. 

The relationship between the logistics and shipping (by any relevant mode of 
transport) and the connectivity with the payment of that shipping function is the "trade 
trigger". The trade trigger is of critical importance to both the seller and buyer, as it 
determines the point in time within the contracted transaction process in which title to 
20 the goods (and thus risk exposure) passes from one party to another. 

Depending on the terms of the core contract negotiated between the parties, the 
fundamental conditions which may require to be satisfied may include: 

• credit and finance 

• transport 
25 • insurance 

• inspection 

Figure 9 is a schematic diagram representing the relationship between the 
procurement module 4 and the sales module 3 in respect of purchase/sales order 
processing functions. This figure illustrates the main categories of conditions which 
30 may require satisfaction before execution of the core contract can be seen as 
proceeding within the scope of the agreement. 

Each of the oval figures in the diagram represents a sub-contract condition 
which must be satisfied in the post transaction phase of the process managed by the 
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search module 2, sales module 3 and processing module 4 of the system 1. Each of 
these conditions, in turn, can be viewed as a "trigger". When appropriate data is 
interfaced into the process, a condition is satisfied which, in turn triggers the process to 
proceed to the next condition. 
5 The final step in the transaction execution process links the sub-contract 

execution functions to a banking function. An important step in the process is the 
issuance of the official shipping document, the bill of lading or air weigh-bill. These 
documents are viewed in law as being documents of title which regulate the time at 
which risk of loss and passage of title to the property occur relative to the terms of the 
core contract. 

Passage of these documents between the shipper, seller and buyer take on the 
added function of signalling the time at which the right of the seller to receive payment 
from the buyer occurs. The most important date is the date of issuance of the relevant 
shipping document. 

The point in the business process at which the actual issuance time is entered 
into the system also represents that point at which the buyer becomes legally obligated 
to make payment to the seller (either now or at a future time). This importance of this 
event is that automated banking functions can now be activated. 

Each of the oval figures in the diagram represents a sub-contract condition 
which must be satisfied in the post transaction phase of the process. Each of these 
conditions, in turn, can be viewed as a 'trigger'. When appropriate data is interfaced 
into the process, a condition is satisfied which, in turn triggers the process to proceed 
to the next condition. 

Data interfacing and integration is a central function of the post-negotiation 
aspect of the described embodiment. The system 1 has been designed to reflect a logic 
that is influenced by two underlying principles: 

• simple logic structures in order to permit easy data manipulation and 
technical programming; while at the same time, 

• maximising process efficiency and accuracy. 
The system functions by: 

• coordinating and combining data from internal and external sources 

• processing data combinations and generating new data 

• consolidating simple data with generated outcomes 
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• sequencing the data manipulation and coordination functions according to 
time and other conditional factors 

The system 1 performs the data interfacing and integration functions described 
above by means of a central coordinating device that controls data interface and data 
5 distribution timing and sequencing. This device, in effect, controls the logic that 
drives the system's internal functions as well as external systems and users. Although 
the overall system 1 performs a number of discrete operations, these operations are 
prompted or controlled by the central coordinating mechanism which is, in turn, tied to 
data interfacing. 

10 In order for the overall system 1 to function properly, it should ideally perform 

systematic data retrieval and storage functions. These functions are made more 
complex given the differing sources of data. The data used includes: 

• simple data which is not manipulated or transformed, but is necessary to the 
transaction 

15 • system generated data (originating from simple data that is transformed) 

This data is entered from several system interfaces (or sources). The data input 
via all interface sources is either stored in database form (and is used at some future 
time) or is used in an immediate processing function. 
The sources of data are: 
20 • real-time data originating from user interfaces 

• system generated data originating from a processing/computation function 

• data originating from interface with intranet systems 

• external data originating from interfacing with other Internet sources 
Given the various sources of data and the differing time requirements for its use, the 

25 system performs and coordinates numerous data prompting, retrieval and allocation 

functions. This provides a foundation for the more complex integration functions 

which are described below. 

Whereas data sourcing and distribution is one integration-related function, the 

system performs integration functions that proceed at a higher level of complexity. At 
30 this level, an underlying systems logic is used to combine technical simplicity in the 

data configuration processes (described above) with process efficiency considerations. 

It is at this level of the integration process where business transaction logic is 

combined with the invention's data logic. 
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Enterprise resource planning (ERP) systems are computer and database 
management systems. ERP systems assist business organizations by improving 
internal process efficiency by linking databases that contain an organizations supply 
chain related activities what the organisation's manufacturing planning, finance and 
5 administration functions. 

ERP systems do not allow for integration of information relating to external 
business transactions. 

The described embodiment of the system 1 includes an interface mechanism 
that allows for the coordination of information between "back-end" computing systems 
10 and "front-end" marketing and transactional activities. 

The interface component uploads relevant data from the host systems: 

• product item master database 

• customer master database 

• manufacturing and planning master database 

15 This uploaded data is consolidated and distributed to the appropriate Internet 

modules; that is, product inventory/display modules, transaction hub module. 

Further, the described embodiment of the system 1 consolidates and distributes 
data and information generated from Internet functions including other support 
services. 

20 In a business transactional sense, concluding a business transaction can be 

viewed as a sequential process of satisfying a series of inter-related, but necessary 
conditions. In a mechanical sense, the process of achieving or satisfying the 
conditionality requirements requires a stepwise and simultaneous: 

• generation of new data by the system's internal functions; or the 
25 • selection and re-configuration of existing data; 

• which is then entered into the system in an appropriate and logical time 
sequence to satisfy the necessary contractual pre-conditions. 

Although stated in simplistic terms above, this function requires the integration 
of data from multiple data sources, a transformation of some of that data as well as a 
30 re-ordering of re-configured untransformed data with newly generated data outcomes. 

A third level of systems logic is now described. The two stages described 
above involve data inputting and processing. The results of these processes creates a 
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new series of values representing variables influencing new equilibrium conditions in 
the post transaction stages of the process. 

The new equilibrium conditions are reflected as data outputs which must be 
properly allocated: 
5 • internally of the system 

• externally of the system but internally within a firm's intranet systems 

• externally to other Internet systems 

The timing and sequencing of the data output distribution and allocation 
process is, in turn, influenced by functions described as part of data interfacing, 
10 processing and integration which simultaneously occur, or have already occurred. 

It will be understood that the invention disclosed and defined in this 
specification extends to all alternative combinations of two or more of the individual 
features mentioned or evident from the text or drawings. All of these different 
combinations constitute various alternative aspects of the invention. 



15 
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CLAIMS 

1. A method of facilitating an e-commerce transaction, the method including: 
providing a set of trading parameters; 

accepting in respect of a first entity a desired trading profile including desired 
5 values or ranges of multiple of said trading parameters; and 

accepting in respect of said first entity one or more further trading profiles 
including values or ranges of multiple of said trading parameters; 

establishing one or more functional relationships between variations in a key 
trading parameter and one or more other of said trading parameters; 
10 wherein each of said further trading profiles are equivalent in desirability or 

expected value to said desired trading profile, and said functional relationship can be 
used to determine a set of equivalent trading profiles having substantially desirability 
equal expected values equivalent to said desired trading profile and said further trading 
profiles. 

15 2. A method according to claim 1, wherein said first entity is a seller and said 
trading profile relates to the trading parameters desired by a seller. 

3. A method according to either one of claims 1 or 2, and further including: 
comparing a submitted trading profile accepted from a second entity against 

equivalent trading profiles of said first entity to determine whether the submitted 
20 trading profile is more favourable to the first entity that said desired trading profile. 

4. A method according to claim 3, wherein trading profiles are generated by or on 
behalf of said first and second entities with an intention to conduct a commercial 
transaction, and are generated at least with a view to determining market demand or 
supply for a product or service to which said trading parameters of said trading profiles 

25 relate. 

5. A method according to either of claims 4 or 5, wherein the second entity is a 
buyer. 

6. A method according to any one of the preceding claims, wherein said trading 
parameters include one or more of: price, volume, payment terms, credit terms and 

30 credit rates of interest. 

7. A method according to any one of the preceding claims, wherein said key 
trading parameter is price. 
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8. A method according to anyone of claims 3 to 7, wherein when said submitted 
trading profile is more favourable than said desired trading profile, a transaction 
between said first and second entities is initiated. 

9. A method according to claim 8, wherein profile which has trading parameter 
5 values which are derived from said submitted trading profile, and/or one or said 

equivalent trading profiles. 

10. A method according to claim 9, wherein said one of said equivalent trading 
profiles is said desired trading profile, or an equivalent trading profile which is closest 
on a minimum squared distance measure or equivalent measure from said submitted 

10 trading profile. 

11. A method according to claims 9, wherein in other embodiments, said 
transaction trading profile represents a compromise between terms of the desired 
trading profile, and terms of the submitted trading profile. 

12. A method according to any one of the preceding claims, wherein said 
15 submitted trading profile is less favourable to said first entity than said desired trading 

profile, steps are performed to establishing a submitted trading profile and a desired 
profile that are compatible. 

13. A method according to claim 12, wherein the steps performed involve a 
modification of the values or ranges of said trading parameters of said submitted 

20 trading profile and/or said desired trading profile. 

14. A method according to claim 13, wherein either or both of said first and second 
entities are suggested what changes could be made to their respective trading entities 
to establish compatible trading profiles. 

15. A method of facilitating an e-commerce transaction, the method including: 
25 providing a set of trading parameters; 

accepting in respect of a first entity a desired trading profile including desired 
values or ranges of one or more of said trading parameters; and generating a metric 
representative of the desired trading profile; 

wherein said metric can be used as the basis for comparing said desired trading 
30 profile with a proposed trading profile. 

16. A method according to claim 15, and further including: 

generating a metric representing the expected value of the desired trading 

profile. 
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17. A method according to either one of claims 15 or 16, and further includes 
accepting from said at least one party multiple desired trading profiles having equal or 
substantially equal expected values. 

18. A method according to claim 17, wherein in each of the equal or substantially 
5 equal desired trading profiles, at least the trading parameter of price is different in each 

profile. 

19. A method according to either one of claims 17 or 18, wherein in each of the 
equal or substantially equal desired trading profiles, changes in price are indexed 
against each of the other trading parameters besides price. 

10 20. A method according to any one of claims 17 to 19, wherein in each of the equal 
or substantially equal desired trading profiles, the sensitivity of the trading parameter 
of price is quantified against each of the other trading parameters. 
21. A method according to claim 21, wherein this relationship is quantified by an 
approximate mathematical expression. 

15 22. A method according to either of claims 20 or 21, wherein the sensitivity of 
price against each of the other trading parameters is independently quantified. 

23. A method according to any one of claims 15 to 22, wherein parties to the 
transaction include a seller and one or more buyers. 

24. A method according to any one of claims 15 to 23, and further including: 

20 performing calculations to determine one or more sets of trading terms which 

agree with the desired values/ranges of the at least two parties. 

25. A method according to any one of claims 15 to 24, wherein the prospective 
buyer and the prospective seller are respectively identified by a search based on a 
product and/or service classification code. 

25 26. A method of identifying prospective partners in an e-commerce transaction, the 
method including: 

providing a product and/or service classification code; 

providing a database of records relating to respective business entities, said 
records including information, indexed according to said classification code, recording 
30 at least one product or service provided by or required by said entity and at least one 
desired trading profile in relation to said at least one product or service; 

performing, in response to supplied search information including at least one 
classification code, and at least one submitted trading profile, a search of said database 
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for entities having a desired trading profile at least compatible with said submitted 
trading profile. 

27. A method according to claim 26, wherein the classification code is organised in 
an hierarchical manner, so that search information of variable specificity or granularity 

5 can be provided. 

28. A method according to either one of claims 25 or 26, wherein said 
classification code is, or is based on or derived from, an internationally recognised 
product and/or service classification code. 

29. A method according to claim 28, wherein the classification code is the 
10 Harmonised Tariff Code, or HTC. 

30. A method according to any one of claims 26 to 29 wherein the search 
information includes supplementary information specific to business organisations, 
such as geographic region, desired trading terms, and credit profile. 

31. A method according to any one of claims 26 to 30, and further including: 
ranking the results of the search by one or predetermined criteria. 

32. A method according to any one of claims 26 to 31, wherein a number of search 
fields can be specified in the search information to increase the specificity of the 
results of the search. 

33. A method according to any one of claims 26 to 32, wherein the search is 
performed by a particular user, and search information preferences specific to that 
particular user are taken into account when conducting the search. 

34. An e-commerce transaction facilitation system including: 
a sales module operatively connected to a first enterprise resource planning 

system of a selling entity; 

a procurement module operatively connected to a second enterprise resource 
planning system of a purchasing entity; and 

a search/directory module, wherein one or more of said modules include a 
processing unit and associated memory unit maintaining computer program code for 
causing the system to perform a method according to any one of the preceding claims. 



WO 01/69460 



PCT/AU01/00299 



1/14 




SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 




SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 





SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 




SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



5/14 




SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



FIGURE 6 



6/14 



Stock Item Procurement 

102 



100 



Purchase Order 
Detail 
-supplier 
-line items 



PO processing 
management 
system 



ERP —101 



103 



Supplier 
Sales 
Module 




FIGURE 7 

Non-Stock Item Procurement 




113 



Purchase Order 
Detail 
-supplier 
-line items 









-110- 




-111- 




-112- 




.102 



PO processing 
management 
system 



103 



Supplier 
Sales Module 




SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



7/14 



CO 

111 

OH 
=> 
O 

IX- 



CO 

c 
"co 

CO 
CD 
O 

2 

Q_ 
i— 

CD 



CO 
_CD 

CO 
CO 

CD 
"P 



CD 
CO 
CO 



co 




CM 



CO 




o 
o 

CO 

•o 

=3 

o 

JO 

•4— » 

=5 

O 



8 

iS 

CL 
CD 
O 

O 
CO 

c: 
o 



o 

j 

o 



c: 

Z3 

o 



cr 
o 

CD 

a: 

"O 

cr 
rs 
o 

c: 



T5 
E 
CD 

0> 



CM 



CO 



SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



8/14 





FIGURE 9A 




FIGURE 9B 


FIGURE 9C 



FIGURE 9 



SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



9/14 




SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



10/14 




Q Q 




Item 



FIGURE 9B 



SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



11/14 



r 

Q Q Q Q Q Q 



PO SO BPO BSO SubPO SSO 




Lineltem 



SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



12/14 



FIGURE 10A 



FIGURE 10B 



FIGURE 10 



SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



13/14 



Q 



«inverse>>, 
#my U 0 M Conversions 
Q0..n 

U 0 M Conversions 



#myltem^ , tem 



1..n 
#allltems 



#myFrom U 0 



#myltems 




ffmyi 

"tin 



#myPrimary U 0 M 
1 

#myUnitOfMeasures 



UnitOfMeasure 



FIGURE 10A 



SUBSTITUTE SHEET (RULE 26) 



WO 01/69460 



PCT/AU01/00299 



14/14 



#allCountries 



SearchManager 
0..n 



#mySystems 
1 >k 

«inverse» 



#mySystems 

SearchSystem 

J 1 .1 V 1 
#mySystem 




#myCountry 



«inverse» 



0..n 



Q 



#myParent #myChildren ^ , 
Code Code 



#myCodes 



#mySystem 

«inverse>> 

#allCurrencies 

,. .._ . , \ Currency #myForeignCurrency 

#allGoodProviders V ' .^3-. 

-1-n \ 1 Tj 

#allServiceProviders r . ^r~, 

ForeignExchange 




#myForeignExchanges 
1..n 



0..n 



0. . 1 #mySubsidiaries 0. .n 
Com P an y Company 



FIGURE 10B 



SUBSTITUTE SHEET (RULE 26) 



